Subject: proposal comments

From: "Peter W. Gayek" <[email-masked]>
Date: Mon, 30 Oct 95 12:41:37 EST

Dave,
Your proposal is a great start - we can really make good progress
with this as the base.  Here are a few comments that I thought
might be worth making before the meeting:

- Overview / Single session TCP connections
  The requirement that mcast-capable DLSws must support a single
  full-duplex TCP connection raises an interesting possibility.
  An ICR_ex UDP receiver already knows before doing capabilities
  exchange that the sender will prefer a single connection, so
  we could say that it is not necessary to go through the process
  of bringing up the dual connections and dropping one.  This would
  save time in the connect sequence, helping with the concern Allen
  mentioned in his post.  But it requires additional logic in the
  ICR_ex sender.

- Capabilities exchange
  The proposal says that on-demand TCP connections are only for
  circuit traffic.  We should discuss what rules apply when two
  nodes that are both multi-cast capable (as seen in capex) bring
  up a pre-configured transport connection.  Does this just mean
  the TC stays up (to avoid the up/down delay), and mcast must
  still be used for address resolution and NB broadcasts?  Do we
  need to distinguish on-demand versus configured / persistent
  TCs in the capex message?

- Multicast Groups and Addressing
  The addresses you suggest, 255.0.1.x, are not within the allowable
  range for class D multicast IP addresses.  Maybe this was just a
  typo transcribing from Mike's post, which used 225.0.1.x.

- NetBIOS, RND support
  It is great to provide suggestions for what frames to multicast
  and what to unicast, but this section seems to limit the ability
  for implementations to apply additional intelligence to forward
  frames to some set of destinations that isn't either 1 or all.
  We would prefer a more general statement that leaves a lot of
  flexibility to the implementation.

- Multicast Capabilities CV
  Having more LT control vectors within a single 0x8C CV seems
  contrary to the philosophy established so far for capabilities
  exchange formats.

- UDP Packets
  We should add to the spec what UDP port number to listen and
  send on.

Looking forward to the discussion on Wednesday....

Peter Gayek
IBM Corp.